IBIS Macromodel Task Group Meeting date: 10 May 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Radek: Motion to approve the minutes. - Dan: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: [Pin Reference] BIRD Draft: - Discussion: Bob suggested that we defer discussion until Walter is available. Bob noted that Walter had sent out a draft for private review. Bob said that he was working on some suggestions and some added examples. Radek asked if he was on the recipients list of the private review email. Bob said he thought so, but would forward it to Radek. Arpad asked if anyone else had any comments or questions on the topic. There were none. - New Redriver Flow: - Fangyi: [sharing his updated "AMI Simulation Flow Round 3" version 4] - I've updated the presentation with Walter's suggestions. - [Slide 3 - Summary] - Walter's first suggestion is reflected in the top row. - RxInit() returns the IR of the non-DFE portion (gain and linear EQ). - Previously RxInit() returned the convolution of the non-DFE portion with the "Rx in partial". (CTLE and non-DFE used as synonyms below). - Walter suggested the RxInit() should only output the CTLE portion. - Tool can do the convolution. - CTLE can also be used by the tool as it wants (cross talk for example). - Input to RxInit() is still the same. - [Slide 5 - Normal Time Domain Flow: if Tx has GetWave] - Inputs are the same. - Model returns CTLE IR. - Model returns DFE IR. - Model must internally perform the convolution of CTLE impulse and the input AC so it can align the DFE cursor with that combined impulse. - Time Domain Simulation: - If Rx has GetWave() - TxGetWave() output is convolved with AC and passed into RxGetWave(). - If Rx is Init-only - EDA tool takes the output of TxGetWave() and convolves it with the AC and with the Rx non-DFE, and on top of that it adds in the convolution of the digital Tx input and the Rx DFE. - Only difference is that AC * Rx non-DFE used to be returned directly by RxInit(). Now the tool has to do the convolution. - Radek: What are the advantages of returning the non-DFE separately, instead of the non-DFE convolved with the AC? - Fangyi: Walter mentioned that their tool has use of the CTLE filter, but he didn't articulate the detail. - One reason I can think of is that if the model doesn't support cross-talk, then the tool can take this CTLE portion and apply it to the cross-talk impulse matrix itself. - Curtis: Originally, Walter had also suggested that we might not have to pass in the cross-talk impulse matrix at all, right? - Fangyi: Yes, that's true. He subsequently clarified that and decided that he also wanted to keep the cross-talk matrices as well. - Need to emphasize that because the model internally performs this convolution (AC * Rx non-DFE) and uses it to align the DFE cursor, and the tool will also perform this convolution, they must do it consistently. We must have raw convolution only, without adding any arbitrary delay. - At times I can imagine a tool or model might remove or add some delay before the main cursor for efficiency reasons. But that would destroy the alignment between the tool's convolution and the DFE taps from the model. - [Slide 6 - Normal Time Domain Flow: if Tx is Init-only] - Same returns from RxInit() (same as slide 5). - Time Domain Simulation: - If Rx has GetWave() - EDA tool just convolves the Tx digital input with the TxInit() output and passes it to RxGetWave(). Same as the current flow. - If Rx is Init-Only - EDA tool convolves the Tx digital input with the blue box output that contains everything. Same as current flow. - Note that the total output (blue box) is the partial input convolved with the Rx CTLE, plus the Rx DFE. This is what current AMI models are doing. - [Slide 7 - Normal Statistical Flow] - Same returns from RxInit() (same as slides 5 and 6). - But the tool will just use the Total output (blue box) to represent the entire system (same as current flow). - [Slide 8 - Redriver Time Domain Flow: If Tx2 has GetWave] - Time Domain Simulation: - If Rx2 has GetWave() - EDA tool convolves the Tx2GetWave() output with AC2 and passes it to Rx2GetWave(). - If Rx2 is Init-only: - EDA tool takes the output of Tx2GetWave() and convolves it with the AC2 and with the Rx2 CTLE, and on top of that it adds in the convolution of the digital Tx1 input and the Rx2 DFE. - This convolution of AC2 and Rx2 CTLE by the tool is the change that was made to incorporate Walter's suggestion. - [Slide 9 - Redriver Time Domain Flow: Init-only Tx2] - Time Domain Simulation: - If Rx2 has GetWave() - EDA tool convolves the Rx1 output with the Tx2Init() output and passes it to the Rx2GetWave(). - If Rx2 is Init-only - EDA tool convolves the Rx1 output with the Tx2Init() output and with the Rx2 CTLE, and on top of that it adds in the convolution of the digital Tx1 input and the Rx2 DFE. - [Slide 10 - Redriver Statistical Flow] - For the victim channel, the Rx total output (blue box) will be used. - For crosstalk, the convolution of the Tx2Init() output and the Rx2 CTLE output will be used for the aggressors that come in from Rx1. - [Slide 11 - Summary] - Updated the definition of the item in the first row (Rx in partial). - The output returned by RxInit() in this location is now just the CTLE of the Rx (gain and linear eq). Before it was the convolution of the CTLE with the Rx in partial. - Update to row 3. - Note that the Rx DFE cursors are aligned to the convolution of the Rx in partial and the Rx CTLE. - Mike: Could you explain again the reason the DFE portion is separated off? - Fangyi: The DFE is extremely non-linear. The filter representation of DFE can only work with a square wave. It doesn't work with a continuous arbitrary wave. - Discussion: Mike wondered if we couldn't focus on something like the "non- linear" portion or something not as specific to a certain technique as "DFE" and "non-DFE" with an eye toward future solutions. Arpad asked if perhaps calling the blocks linear and non-linear would work, but Fangyi noted that the actual combinations of terms, like adding in the DFE convolved with the square wave Tx Input, were specific to DFE and not just a general "non-linear" block. Mike noted that he was just suggesting that we keep an eye toward using terminology as general as possible. - Fangyi: [Slide 12 - New Reserved Parameters] - Based on the last discussion, we decided we could use one parameter as per Walter's suggestion. - New single parameter indicating newly proposed flow. - Optional, Boolean, In, Default = False, Format = List {False, True}. - Its presence in the .ami file indicates the model supports BOTH the proposed and current (6.1) flows. - A model that supports the proposed flow must also support the 6.1 flow. - If the parameter is not specified in the .ami file, the tool executes the 6.1 flow without passing this parameter in to AMI_Init(). - If it is specified in the .ami file, and the EDA tool wants to execute the new flow, then it sets the value to true and passes it in to AMI_Init(). - If it is specified in the .ami file, and the EDA tool wants to execute the 6.1 flow, then it would not set its value in the string passed to AMI_Init(). - Discussion: Radek commented that the second and third bullet points were restating the same thing, both lines stated that a model that supported the proposed flow must also support the 6.1 flow. Fangyi said the third point emphasizes that a model must support both flows if it supports the proposed flow, it cannot support only the newly proposed flow. Arpad asked if the intention was to allow a model that advertised itself as "6.2" to only support the 6.1 flow. Fangyi said yes, there is no intention to rely on the version parameter and force any model greater than 6.1 to support the new flow. Arpad asked if there would be a problem in a redriver channel if one Rx supported the new flow and the other only the 6.1 flow. Fangyi said he had considered that possibility and believed that such a mixed environment would work properly. Fangyi expressed some reservations about the last bullet point, which said the tool should not set the value if it wants to use the 6.1 flow. Radek said a tool that recognizes the parameter should be able to set it to false (as opposed to not setting it at all). Curtis pointed out that the bullet point implied the model should treat "false" as the default in case a tool that didn't understand the parameter didn't pass it at all. Fangyi agreed that this was the case he was considering with that bullet point. Some people expressed concerns about what EDA tools using old parsers would do with these new parameters, but this was viewed as something that affects any new parameters not these in particular. Mike reiterated his thought from an earlier meeting that using a single parameter for what could be considered two way communication between the model and the tool was not ideal. Mike suggested that an Info parameter could be used by the model to advertise its support for the proposed flow, and a different In parameter could be used by the tool to select the flow it wanted to use. Fangyi agreed that he felt that Walter's single parameter suggestion amounted to hacking the parameter. Fangyi noted that he had originally proposed two parameters (see v3 of the document, posted April 19, 2016). The group reviewed Fangyi's earlier two parameter proposal. Fangyi said he would prepare a version that reverted to the two parameter approach, and asked for suggestions for improved names for the two parameters. Name suggestions based on "Rx Supports" for the Info parameter and "Simulator chooses" for the In parameter were made. - Mike: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 17 May 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives